Having a permissive Cross-Origin Resource Sharing policy is security-sensitive. It has led in the past to the following vulnerabilities:
Same origin policy in browsers prevents, by default and for
security-reasons, a javascript frontend to perform a cross-origin HTTP request to a resource that has a different origin (domain, protocol, or port)
from its own. The requested target can append additional HTTP headers in response, called CORS, that act like directives for the browser and change the access control policy
/ relax the same origin policy.
Ask Yourself Whether
- You don’t trust the origin specified, example:
Access-Control-Allow-Origin: untrustedwebsite.com.
- Access control policy is entirely disabled:
Access-Control-Allow-Origin: *
- Your access control policy is dynamically defined by a user-controlled input like
origin header.
There is a risk if you answered yes to any of those questions.
Recommended Secure Coding Practices
- The
Access-Control-Allow-Origin header should be set only for a trusted origin and for specific resources.
- Allow only selected, trusted domains in the
Access-Control-Allow-Origin header. Prefer whitelisting domains over blacklisting or
allowing any domain (do not use * wildcard nor blindly return the Origin header content without any checks).
Sensitive Code Example
<!-- Tomcat 7+ Cors Filter -->
<filter>
<filter-name>CorsFilter</filter-name>
<filter-class>org.apache.catalina.filters.CorsFilter</filter-class>
<init-param>
<param-name>cors.allowed.origins</param-name>
<param-value>*</param-value> <!-- Sensitive -->
</init-param>
</filter>
Compliant Solution
<!-- Tomcat 7+ Cors Filter -->
<filter>
<filter-name>CorsFilter</filter-name>
<filter-class>org.apache.catalina.filters.CorsFilter</filter-class>
<init-param>
<param-name>cors.allowed.origins</param-name>
<param-value>https://trusted1.org,https://trusted2.org</param-value> <!-- Compliant -->
</init-param>
</filter>
See
